=programming
A bridge is a tool for getting
from one physical point to another. Software is a tool for getting from one
conceptual point to another.
Bridges make movement in one direction
easier, but in doing so, they inevitably make movement in other directions
harder. Some bridges are also continuous walls, while others have only
sparse support columns that can be walked between. Software is analogous.
For example, regular expressions have escaping to make it possible (but more
awkward) to write anything you can write in a plain string. Other systems do
a few things efficiently but allow only a small subset of what can be
expressed without them.
It's possible for bridges to have supports
that are few and distant, but the supports must still carry the full weight
of the bridge. Similarly, in software, the conceptual space taken up by
supports increases with capabilities. That's the information-theoretic
limitation: making instructions for some things shorter requires making
other instructions longer. It's possible to provide a route through the
"supports" by providing a fallback to a general-purpose programming
language, but sometimes bridges are meant to also be walls, for security.
However, the obstructions of
software frameworks are much greater than adding an extra character to other
function names. To me, that's like how it's hard to go from the top of a
bridge to ground level and back. Sometimes people call that "impedance
mismatch", but I don't think signal attenuation caused by partial reflection
is the best metaphor here.
It's possible to build ladders and stairs
to make it easier to go between the ground and the top of a bridge, but
that's extra work and can obstruct widening the bridge later. Alternatively,
the bridge can be made so wide that you rarely need to go down to ground
level, but obviously that's very expensive; only the largest projects can
mostly-accomplish that.
What, then, is the most important
skill when making a bridge? Is it understanding the subsurface to make
stable foundations so the bridge won't shift? Is it making the top of the
bridge smooth so it can be crossed quickly? Those are valuable, but I'd say
what's most important is knowing where to build a bridge and where not to.
Doing that well requires understanding where people need to go and don't
need to go - which is different from where they currently go, because
movement can change once a bridge is made.
Without careful design,
you might find yourself high in the
sky and traveling through
buildings.
In an open field, going to a
destination is simple: walk towards it. Going a long distance may be a lot
of work, but the route doesn't require much planning. Similarly, large
matrix multiplications may involve a lot of computation, but they're easy to
plan out and specify.
A road trip can be much harder to plan, because
roads add complexity to the space being traveled, but not all road systems
are equally difficult to navigate. A dense grid of streets is easy to find a
route through, while in some places, it might be necessary to sometimes
drive away from the destination in non-obvious ways. If it's hard to find a
route to your destination, possible reasons include:
- You know
some things about your destination, but not its actual location.
- Your
maps are outdated or incomplete.
- You want to avoid a highway with
excessively high tolls.
- Part of your route doesn't get enough traffic
to justify having usable roads.
- The road system wasn't designed for
your use case, so you have to take a poorly-marked side street.
- The
overall road planning wasn't coordinated, so all the long-distance paths are
meandering, longer and less direct than they should be.
The analogies of those to software are left as an exercise for the reader.
The hot topic for programming
right now is LLMs. In general, people find it easier to express what they
want in english than programming languages, but there are many cases where
an experienced programmer finds it easier to write code for what they want
than to explain it in english, and whether that's the case depends on how
well the programmer knows the language and whether it has good
representations of the relevant abstractions. The advantage of english over
programming languages is largely that it's a standard that people already
know and that an enormous amount of work has gone into the library of
concepts and examples that english can use - you can easily express things
that don't have functions to call only because someone else developed the
concepts used. On the other hand, trying to express in english some things
that are simple in programming languages can end up like
this.
In the "bridge"
metaphor, this is like english being on a different level than programming
languages, and having many wide bridges in every direction, but those
bridges weren't designed for cars and the paths are crooked. If we imagine
that LLMs only used some obscure language without words for many modern
concepts, would people use them? If LLMs could only use, say, ancient Mayan,
would people go to the trouble of learning it to use them for programming? I
doubt it.
English does have a major advantage over programming
languages in general, in that you can choose a word based on meaning instead
of needing the exact name of a function or variable. This is basically
vector encoding and vector similarity search of words and phrases mostly
compensating the the misalignment of interfaces between parties. Of course,
it is possible to use vector similarity search to choose the right function
name when someone uses the wrong word, but that alone isn't enough. People
communicating with english also handle small misalignment at higher
conceptual levels, like action combinations and intents. Natural language is
like a rough cobblestone path, which is fine for walking on because people
can see where to put their feet at each step, but conventional software is
like a train that can carry heavy payloads and move quickly but requires
train tracks that must be continuously aligned. LLMs are then like recent
humanoid robots, which are expensive and recent developments but can handle
rougher terrain than wheeled vehicles.